fix(core): add DeepSeek V4 Flash Vision to model metadata - #3605
fix(core): add DeepSeek V4 Flash Vision to model metadata#3605yunaremaia wants to merge 2 commits into
Conversation
deepseek-v4-flash-vision-exp is returned by the first-party /models endpoint but was absent from STATIC_MODEL_METADATA, causing Maka to classify it as text-only and filter image attachments before the request reaches the provider. Add the model ID with vision capability to both STATIC_MODEL_METADATA and CURATED_CATALOG_FALLBACK_MODELS so the existing DeepSeek adapter passes image content through. Fixes: apache#3417 Signed-off-by: Yunare Maia <yunare@gmail.com>
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Reviewed at exact head d74bb28c0af711063db5c77084fdd06962a279e2. No [P0]–[P2]. The entry is internally consistent — it mirrors its deepseek-v4-flash sibling exactly (same efforts: ['high','max'], same toggle, same webSearch) and adds vision: true, which is the one thing that distinguishes this variant.
Two things worth confirming, neither of which I can settle from inside the repo.
The model ID has to be exactly what the API accepts. Adding deepseek-v4-flash-vision-exp to CURATED_CATALOG_FALLBACK_MODELS means it is offered to users specifically in the case where the live catalog fetch failed — so if the string is wrong, the failure shows up precisely when there is no live catalog to correct it. Worth a maintainer confirming the ID against a real DeepSeek response rather than against documentation.
vision: true is a hard declaration here. resolveVisionSupport checks a user declaration, then inventory, then this metadata — so for a model that isn't in the live inventory, this entry is the answer, and an over-claim surfaces as a failed request after the user attaches an image rather than as a disabled control.
[P3] No lastUpdated
The neighbouring deepseek-v4-pro carries lastUpdated: '2026-08-13' while both flash entries omit it. Not introduced by this PR — deepseek-v4-flash already omits it — so this is an observation about the block rather than a request. Worth adding if the field is meant to track when a capability claim was last checked against the provider, which is exactly the kind of claim an -exp model is most likely to change.
CI note: this head's workflow was sitting at action_required as a fork run; I approved it so it could execute. Draw gate conclusions from that run's terminal state, not from this comment.
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Reviewed at exact head 9287cdfe781bbac1f1673ccf23f0d62bbf7f8745 (biome-formatting follow-up to d74bb28c0a; delta is line-wrapping only). One [P3] inline; no [P0]–[P2].
This pass also settles the two external confirmations the earlier review left open, checked against the current official DeepSeek API docs:
- Model ID:
deepseek-v4-flash-vision-expis exactly the id listed on the Models & Pricing and Your First API Call pages (model versionDeepSeek-V4-Flash-Vision-Exp), so the fallback-catalog entry matches what the API accepts even in the no-live-catalog case. vision: true: the Vision guide documents image input for this model (JPEG/PNG/GIF/WebP via base64 / external URL / Files API) and the pricing page bills images as input tokens, so the capability claim is backed by upstream.
Two more spot-checks that pass: webSearch: true matches the Responses API guide's server-side web_search tool (with web_search_call passthrough explicitly covered for this model), and toggle: true matches "supports both non-thinking and thinking (default) modes" on the pricing page.
Gate: test is the only path-filtered check this change can trigger and it is terminal green on this exact head.
| }, | ||
| 'deepseek-v4-flash-vision-exp': { | ||
| capabilities: { vision: true, ...REASONING_FUNCTION_CALLING, webSearch: true }, | ||
| thinkingOptions: { efforts: ['high', 'max'], toggle: true }, |
There was a problem hiding this comment.
[P3] efforts here is ['high', 'max'] but every current upstream source lists low for this model, so the menu will be missing the cheapest effort option.
- models.dev lists
deepseek-v4-flash-vision-expwith toggle + effort values['low', 'high', 'max'](last updated 2026-08-21, the release date). - The official Thinking Mode guide accepts
reasoning_effort: low/high/max. - The
deepseek-v4-proentry just below already pins['low', 'high', 'max'](lastUpdated 2026-08-13).
The value looks copied from the deepseek-v4-flash sibling above, whose pinned set predates its 0731 refresh (models.dev now lists flash as low/high/max too). Suggested fix: efforts: ['low', 'high', 'max'].
(Separate observation, not for this PR: the deepseek-v4-flash static entry has the same staleness and might deserve its own follow-up so the next model doesn't inherit it.)
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Reviewed on exact head 9287cdfe781bbac1f1673ccf23f0d62bbf7f8745. Holding off on approval for one finding, inline below.
Everything else checks out. The model ID matches the official pricing and First API Call pages verbatim; vision is backed by the official Vision guide and by images being billed as input tokens; webSearch (Responses API web_search) and toggle (thinking on by default, can be turned off) both verified. Two items left open by an earlier review round are now closed.
Gating: only test is triggered here — no package.json/lockfile or sandbox paths — and it is terminal success on this exact head. So the sole thing standing between this and approval is the effort list.
| }, | ||
| 'deepseek-v4-flash-vision-exp': { | ||
| capabilities: { vision: true, ...REASONING_FUNCTION_CALLING, webSearch: true }, | ||
| thinkingOptions: { efforts: ['high', 'max'], toggle: true }, |
There was a problem hiding this comment.
[P2] efforts: ['high', 'max'] is missing 'low'.
Three independent sources agree this model exposes low/high/max: the models.dev entry (refreshed 2026-08-21, toggle plus low/high/max), the official Thinking Mode docs (reasoning_effort accepts low/high/max), and deepseek-v4-pro two entries below, which already pins ['low', 'high', 'max'].
The likely origin is visible in the file: the sibling deepseek-v4-flash entry directly above carries the same ['high', 'max'], which is a stale high-water mark from before the 07-31 refresh. This entry appears to have inherited it.
I am grading this P2 rather than P3, and I want to be explicit that I am raising a colleague's grade. The reasoning: this PR's entire purpose is to add correct metadata for one model. A wrong effort list is not a peripheral nitpick here — it is a defect in the single thing being added, and it is user-visible, since the effort menu simply will not offer low for this model. Merging as-is would ship the exact error the change set out to prevent, and the fix is one array element.
Separately, and explicitly not part of this PR: deepseek-v4-flash above looks stale for the same reason. Worth a follow-up, but please do not widen this PR to cover it.
2 participants
Summary
Registers
deepseek-v4-flash-vision-expin the model metadata so Maka correctly recognizes its image input capability and passes attachments through to the DeepSeek adapter.Fixes #3417
What changed
STATIC_MODEL_METADATA.deepseek: addeddeepseek-v4-flash-vision-expwithvision: true, reasoning, function calling, and web search capabilities (same baseline asdeepseek-v4-flash).CURATED_CATALOG_FALLBACK_MODELS.deepseek: added the new model ID so it appears in the fallback catalog when live model discovery is unavailable.How it fixes the bug
resolveModelVisionSupport()checksSTATIC_MODEL_METADATAwhen the model ID is not in the stored inventory. Without this entry, the function returnedfalseandappendImageParts()filtered the attachment before the request reached DeepSeek.Testing
deepseek-v4-flashentry, withvision: trueadded.resolveModelVisionSupporttests exercise the metadata lookup path, and the new entry is structurally identical to existing entries.npm installlocally (blocked by@xterm/xtermregistry fetch on this host).AI disclosure
OpenAI Codex assisted with codebase analysis. I reviewed the diff and take responsibility for the contribution.
Signed-off-by: Yunare Maia yunare@gmail.com